GermanWikipedia - /page/entry.mu

Micron Document

<!DOCTYPE html>

<title>White-Box-Test</title>

</head>

<h1 id="firstHeading" class="firstHeading mw-first-heading"><span class="mw-page-title-main">White-Box-Test</span></h1>

</header>

</div>

<div id="mw-content-text" class="mw-body-content mw-content-ltr" lang="de" dir="ltr"><div class="mw-content-ltr mw-parser-output" lang="de" dir="ltr"><p>Der Begriff <b>White-Box-Test</b> (seltener auch <b>Glass-Box-Test</b>) bezeichnet eine Methode des <a href="Software-Test" class="mw-redirect" title="Software-Test">Software-Tests</a>, bei der die Tests mit Kenntnissen über die innere Funktionsweise des zu testenden Systems entwickelt werden. Im Gegensatz zum <a href="Black-Box-Test" title="Black-Box-Test">Black-Box-Test</a> ist für diesen Test also ein Blick in den <a href="Quelltext" title="Quelltext">Quellcode</a> gestattet. D. h., es wird am Code geprüft.

</p><p>Ein Beispiel für einen White-Box-Test ist ablaufbezogenes Testen (<a href="Kontrollflussorientierte_Testverfahren" title="Kontrollflussorientierte Testverfahren">Kontrollflussorientierte Testverfahren</a>), bei welchem der Ablaufgraph im Vordergrund steht. Qualitätskriterium des Tests ist es, sicherzustellen, dass Testfälle in Bezug auf die Überdeckung des Quellcodes gewisse <i>Hinlänglichkeitskriterien</i> erfüllen. Gängig sind dabei u. a. folgende Maße (bzw. Qualitätskriterien):

</p>

<ul><li><i>Zeilenüberdeckung</i>: Ausführung aller Quellcode-Zeilen</li>

<li><i>Anweisungsüberdeckung</i> bzw. <i>Knotenüberdeckung</i>: Ausführung aller Anweisungen</li>

<li><i>Zweigüberdeckung</i> bzw. <i>Kantenüberdeckung</i>: Durchlaufen aller möglichen Kanten von Verzweigungen des Kontrollflusses</li>

<li><i>Bedingungsüberdeckung</i> bzw. <i>Termüberdeckung</i> (mehrere Varianten): Durchlaufen aller möglichen ausschlaggebenden Belegungen bei logischen Ausdrücken in Bedingungen</li>

<li><i>Pfadüberdeckung</i> (mehrere Varianten): Betrachtung der Pfade durch ein Modul</li></ul>

<p>Die Zahl der benötigten Testfälle für die einzelnen Maße unterscheidet sich z. T. deutlich. Kantenüberdeckung wird im Allgemeinen als minimales Testkriterium angesehen. Je nach Art und Struktur der zu testenden Software können andere Maße für ein System als Ganzes oder für Module sinnvoll sein.

</p><p>Selbst wenn ein Softwaresystem in Bezug auf ein Hinlänglichkeitskriterium erfolgreich getestet wurde, schließt das nicht aus, dass es Fehler enthält. Dies liegt in der Natur des White-Box-Tests begründet und kann eine der folgenden Ursachen haben:

</p>

<ul><li>Der White-Box-Test leitet Testfälle nicht aus der Spezifikation des Programms her, sondern aus dem Programm selbst. Getestet werden kann nur die Korrektheit eines Systems, nicht, ob es eine geforderte <a href="Semantik" title="Semantik">Semantik</a> erfüllt.</li>

<li>Auch wenn alle Programmpfade getestet worden sind, bedeutet dies nicht, dass ein Programm fehlerfrei arbeitet. Der Fall, dass im Graphen des Kontrollflusses Kanten fehlen, wird nicht erkannt.</li></ul>

<p>Zusammenfassend kann man sagen, dass White-Box-Tests alleine als Testmethodik nicht ausreichen. Eine sinnvolle Testreihe sollte Black-Box-Tests und White-Box-Tests kombinieren. Nach der Überdeckungsmessung der Testfälle des Black-Box-Tests (durch ein geeignetes Werkzeug) werden durch Betrachten der nicht überdeckten Codeteile neue Testfälle aufgestellt, um die Überdeckung zu erhöhen.

</p><p>Will man ein System auch in seinen Teilsystemen testen, benötigt man dazu Kenntnisse über die innere Funktionsweise des zu testenden Systems. White-Box-Tests eignen sich besonders gut, um in Erscheinung getretene Fehler zu lokalisieren, d. h., die fehlerverursachende <a href="Modul_(Softwarearchitektur)" class="mw-redirect" title="Modul (Softwarearchitektur)">Komponente</a> zu identifizieren und als <a href="Regressionstest" title="Regressionstest">Regressionstest</a> ein Wiederauftreten des Fehlers bereits in der Komponente zu vermeiden.

</p><p>Weil die Entwickler der Tests Kenntnisse über die innere Funktionsweise des zu testenden Systems besitzen müssen, werden White-Box-Tests von demselben Team, häufig sogar von denselben Entwicklern entwickelt wie die zu testenden Komponenten. Spezielle Testabteilungen werden für White-Box-Tests in der Regel nicht eingesetzt, da der Nutzen speziell für diese Aufgabe abgestellter Tester meist durch den Aufwand der Einarbeitung in das System eliminiert wird.

</p>

<div class="mw-heading mw-heading2"><h2 id="Vergleich_mit_Black-Box-Tests">Vergleich mit Black-Box-Tests</h2></div>

<p>White-Box-Tests werden eingesetzt, um Fehler in den Teilkomponenten aufzudecken und zu lokalisieren, sind aber aufgrund ihrer Methodik kein geeignetes Werkzeug, Fehler gegenüber der <a href="Spezifikation" title="Spezifikation">Spezifikation</a> aufzudecken. Für letzteres benötigt man Black-Box-Tests. Zu bedenken ist auch, dass zwei Komponenten, die für sich genommen korrekt gemäß ihrer jeweiligen Teilspezifikation arbeiten, zusammen nicht zwangsläufig eine korrekte Einheit gemäß der Gesamtspezifikation bilden. Dies kann durch Black-Box-Tests leichter festgestellt werden als durch White-Box-Tests.

</p><p>Im Vergleich zu <a href="Black-Box-Test" title="Black-Box-Test">Black-Box-Tests</a> sind White-Box-Tests wesentlich einfacher in der Durchführung, da sie keine besondere organisatorische Infrastruktur benötigen.

</p><p>Vorteile von White-Box-Tests gegenüber Black-Box-Tests

</p>

<ul><li>Testen von Teilkomponenten und der internen Funktionsweise</li>

<li>Geringerer organisatorischer Aufwand</li>

<li>Automatisierung durch gute Tool-Unterstützung</li></ul>

<p>Nachteile von White-Box-Tests gegenüber Black-Box-Tests

</p>

<ul><li>Erfüllung der Spezifikation nicht überprüft</li>

<li>Eventuell Testen „um Fehler herum“</li></ul>

<p>Zudem sei genannt, dass die Unterscheidung zwischen Black-Box-Test und White-Box-Test teilweise von der Perspektive abhängt. Das Testen einer Teilkomponente ist aus Sicht des Gesamtsystems ein White-Box-Test, da für das Gesamtsystem aus der Außenperspektive keine Kenntnisse über den Systemaufbau und damit die vorhandenen Teilkomponenten vorliegen. Aus Sicht der Teilkomponente wiederum kann derselbe Test unter Umständen als Black-Box-Test betrachtet werden, wenn er ohne Kenntnisse über die Interna der Teilkomponente entwickelt und durchgeführt wird.

</p>

<div class="mw-heading mw-heading2"><h2 id="Literatur">Literatur</h2></div>

<ul><li>Andreas Spillner, Tilo Linz: <i>Basiswissen Softwaretest – Basiswissen Softwaretest: Aus- und Weiterbildung zum Certified Tester: Foundation Level nach ISTQB-Standard.</i> 3., überarbeitete und aktualisierte Auflage, dpunkt.verlag GmbH, Heidelberg 2005, ISBN 3-89864-358-1.</li>

<li>Lee Copeland: <i>A Practitioner's Guide to Software Test Design.</i> first printing, Artech House Publishers, Norwood MA, USA 2003, ISBN 1-58053-791-X.</li>

<li>BCS SIGIST (British Computer Society Specialist Interest Group in Software Testing): <a rel="nofollow" class="external text" href="http://www.testingstandards.co.uk/BS7925_3_4.zip"><i>Standard for Software Component Testing</i></a> (<a href="ZIP-Dateiformat" title="ZIP-Dateiformat">ZIP</a>; 340 kB), Working Draft 3.4, 27. April 2001.</li></ul>

<div class="mw-heading mw-heading2"><h2 id="Siehe_auch">Siehe auch</h2></div>

<ul><li><a href="Anweisungs%C3%BCberdeckungstest" class="mw-redirect" title="Anweisungsüberdeckungstest">Anweisungsüberdeckungstest</a></li>

<li><a href="Bedingungs%C3%BCberdeckungstest" title="Bedingungsüberdeckungstest">Bedingungsüberdeckungstest</a></li>

<li><a href="Zweig%C3%BCberdeckungstest" class="mw-redirect" title="Zweigüberdeckungstest">Zweigüberdeckungstest</a></li>

<li><a href="Pfad%C3%BCberdeckungstest" class="mw-redirect" title="Pfadüberdeckungstest">Pfadüberdeckungstest</a></li>

<li><a href="Testmethode" class="mw-redirect mw-disambig" title="Testmethode">Testmethoden</a></li></ul></div><div><div class="zim-footer">

Dieser Artikel wurde von <a class="external text" title="Zuletzt bearbeitet am 2025-03-10" href="https://de.wikipedia.org/wiki/?title=White-Box-Test&oldid=254087054">Wikipedia</a> herausgegeben. Der Text ist unter <a class="external text" href="https://creativecommons.org/licenses/by-sa/4.0/deed.de">Creative Commons Attribution-Share Alike 4.0</a> verfügbar, sofern nicht anders angegeben. Für die Mediendateien können zusätzliche Bedingungen gelten.

</div>

</div></div>

</div>

</main>

</div>

</body></html>